This invention relates to software program modules. More particularly, this invention relates to a method and system for verifying and storing documents during a failure in a spreadsheet application program.
Despite the best efforts of software developers, spreadsheet application programs (xe2x80x9cSAPsxe2x80x9d), such as the xe2x80x9cEXCELxe2x80x9d application program manufactured and sold by Microsoft Corporation of Redmond, Wash., inevitably fail at one time or another. For example, network connectivity problems, viruses, and anti-virus software may cause failures in a SAP. Unhandled failures may result in a crash, at which time the operating system terminates the application program execution. When a program crashes, all of its state data is lost. As a result, users that were in the process of modifying a spreadsheet, may lose substantial amounts of information. Information loss may create a significant amount of work and frustration to users.
To minimize the information lost as a result of a crash, different approaches have been taken. For example, one prior art method comprises performing a normal save of the open document immediately after a failure is detected as if the failure never occurred.
Attempting to save the document after a failure, however, can often cause another failure while saving the document. If the save attempt is unsuccessful then the modified changes in the document are lost and no other attempt is made to recover the information. Furthermore, even if the save attempt is successful, the document may include corruption that prevents the application program in which the failure occurred from reopening the document.
Because the application program may not be able to open corrupt files, the user may still lose substantial amounts of work. Therefore, unless the open files are repaired before they are saved to non-volatile memory, merely saving the files after a failure in the SAP may not provide any benefit to the user.
Accordingly, there is a need for a method and system for saving the
There is also a need for a method and system for verifying the contents of an open file to determine whether the file has been corrupted, possibly as a result of the same problems that led to the application failure.
There is still an additional need for a method and system for verifying the contents of an open file that is sufficiently robust to recover information from severely corrupt files.
The present invention satisfies the above-described needs by providing a method and system for verifying and storing documents during a program failure. A crash handler is provided that verifies and performs an emergency save of any file that is open at the time of the crash.
Once a failure of the program module is detected, control passes to an exception handler, which instructs the operating system to execute the crash handler. The crash handler attempts to repair and store all open files that have been modified. When the program is restarted, the repaired files are loaded and displayed to the user with a list of any repairs.
More particularly, once a failure occurs in an application program module, the operating system passes control to the exception handler, which may display a user interface, such as a dialog box, asking the user whether any open files should be saved.
If the user selects to save the open files, then a determination is made whether the open file has been modified from the version currently saved to disk. If so, the exception handler instructs the operating system to execute the crash handler.
After assuming control, the crash handler examines each file for evidence of corruption. The term corruption is used generally to include any type of error ranging from missing end-of-file markers and illegal names for sheets or ranges, to missing PivotTable report supporting records or corrupt OLE storage structures.
If corruption is found, the crash handler determines whether the errors are repairable. Repairs may include making changes to the file such as renaming sheets or removing parts of the file that contain the errors.
The extent of information recovered by the crash handler depends on the extent the file could be repaired. For example, in accordance with one embodiment of the present invention, if it is determined that the file is so badly damaged that it can not be repaired, the crash handler may not attempt to save the file at all. If, on the other hand, it is determined that the file is not corrupt or that be saved normally, i.e., full normal save.
Alternatively, if the file is determined non-repairable (but not so badly damaged to abort the save), the crash handler attempts to save only the formulas and values of each document""s cell table. All other features such as formatting, Visual Basic for Applications macro programs (xe2x80x9cVBA projectsxe2x80x9d), embedded OLE objects, charts, and PivotTable reports are discarded.
Finally, if the crash handler determines the application program module is in such an unstable state that it may not safely save any files, all saves are aborted. In any case, if repairs are made to a file, a list of all changes is saved with the file, which permits a user to view the changes after the repaired file is reopened in a new instance of the program module.
Although the present invention has been described above as implemented in a preferred application program module, it will be understood that alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its spirit and scope. Accordingly, the scope of the present invention is defined by the appended claims rather than the foregoing description.